语雀突发 P0 级事故！宕机 8 小时被网友怒喷，运维又背锅？
转自：InfoQ （ID：infoqchina ）
整理：凌敏
10 月 23 日 14 时左右，蚂蚁集团旗下的在线文档编辑与协同工具语雀发生服务器故障，在线文档和官网目前均无法打开。当日 15 时，语雀发布官方声明称，“目前因网络故障，出现无法访问的情况。此故障不会影响用户在语雀存储的数据，不会引起数据丢失，我们正在紧急恢复中，再次抱歉给你带来的损失。”
随后，“语雀崩了”登上话题热搜，有网友表示自己的公司项目文档都在语雀上，文档打不开严重影响工作进度；有网友将自己整理的面试题放在了语雀上，宕机时正好赶上电话面试，想查答案都无从下手；也有网友对语雀的运维提出质疑，认为“长时间的故障明显是存储出现了问题，用户数据可能丢失了，在紧急恢复”。
23 日 22:24，语雀发布声明称，“服务现已全部恢复正常，用户访问各端语雀都可正常使用。今日故障严重干扰了所有语雀用户的使用，对此我们深感抱歉。后续我们将发布正式公告同步情况。”
从故障发生到完全恢复正常，语雀整个宕机时间将近 8 小时，如此长时间的宕机已经达到了 P0 级事故，并在网络上引发巨大讨论。
10 月 24 日 21 时，语雀发布官方公告，详述了 23 日故障原因及处理过程，并发布了赔偿方案。语雀表示：“这次的故障让我们深切地感受到了用户对语雀的依赖以及语雀肩上的重大责任。再次向所有语雀用户表达我们诚挚的歉意。我们将持续提升语雀的服务质量和服务稳定性，不辜负每一位用户的信任！”
故障原因及处理过程
据语雀公告，10 月 23 日下午，服务语雀的数据存储运维团队在进行升级操作时，由于新的运维升级工具 bug，导致华东地区生产环境存储服务器被误下线。受其影响，语雀数据服务发生严重故障，造成大面积的服务中断。为了尽快恢复服务，语雀和数据存储运维团队全力进行数据恢复工作，但受限于恢复方案、数据量级等因素，整体用时较长。具体过程如下：
14:07 数据存储运维团队收到监控系统报警，定位到原因是存储在升级中因新的运维工具 bug 导致节点机器下线；
14:15 联系硬件团队尝试将下线机器重新上线；
15:00 确认因存储系统使用的机器类别较老，无法直接操作上线，立即调整恢复方案为从备份系统中恢复存储数据；
15:10 开始新建存储系统，从备份中开始恢复数据，由于语雀数据量庞大，此过程历时较长，19 点完成数据恢复，同时为保障数据完整性，在完成恢复后，用时 2 个小时进行数据校验；
21 点存储系统通过完整性校验，开始和语雀团队联调，最终在 22 点恢复语雀全部服务。用户所有数据均未丢失。
语雀表示，作为一款服务千万级客户的文档产品，通过这次故障深刻认识到，应该做到更完善的技术风险保障和高可用架构设计，尤其是面向技术变更操作的“可监控，可灰度，可回滚”的系统化建设和流程审计，从同 Region 多副本容灾升级为两地三中心的高可用能力，设计足够的数据和系统冗余实现快速恢复，并进行定期的容灾应急演练。只有这样，才能提升严重基础设施故障时的恢复速度，并从根本上避免这类故障再次出现。
为此语雀制定了如下改进措施：
升级硬件版本和机型，实现离线后的快速上线。该措施在本次故障修复中已完成；
运维团队加强运维工具的质量保障与测试，杜绝此类运维 bug 再次发生；
缩小运维动作灰度范围，增加灰度时间，提前发现 bug；
从架构和高可用层面改进服务，为语雀增加存储系统的异地灾备。
此外，语雀团队还公布了赔偿方案：
针对语雀个人用户，赠送 6 个月的会员服务。操作流程：进入工作台「账户设置」，点击左侧「会员信息」，在会员信息页面点击「立即领取」，即可获得赠送服务。
针对语雀空间用户，由于情况比较复杂，语雀团队会单独制定赔偿方案。请空间管理员留意语雀站内信。
语雀崩了，开发者怎么看？
语雀的宕机事件在网络上引发巨大讨论，有网友对在线文档的可靠性提出质疑，有网友调侃语雀的运维手册是不是写在了语雀文档上，也有网友分析语雀创始人玉伯离职后，语雀是否已经走到了“生死局”，有被阿里放弃的可能？
网友想喝阔落 de 阿七认为，最基础的信息安全是知识库类工具最根本的竞争力，如果今后再出现类似情况导致数据丢失，亡羊补牢的赔偿都是无济于事的。而且语雀的后续改进方案中只字未提本地离线存储功能的开发，那么将如何保证用户数据的万无一失？
知乎网友 @段小草从云服务故障角度进行了分析，他认为在线文档的可靠性和信任问题是所有云服务面临的问题：
云服务不可靠性的问题是无解的，只能从理论上讲，用户越多的大厂产品，运维保障能力越强，理论上会越有保障。但这样的时候我们是需要取舍的，比如像 OpenAI 的 API 服务，如果没有任何的一家产品能提供与之相当的服务，那就只能祈祷它不出问题；但如果可以，就要有容灾的备选，甚至做一个本地模型顶上，哪怕性能不如 GPT-4 也可以最大程度地保证业务不中断。
但像笔记软件这种，其实可选产品很多，本地软件也有，再把身家性命系到唯一的在线服务上就没那么明智了。如果没有协作需求，完全可以自己离线。即便有多人联网协作需求，语雀这次的宕机过后，相信笔记软件之间的互相备份，或者像题主提到的本地存储 + 云端备份 + 多人协作的想法，也会有相应的解决方案。
知乎网友 @王半山认为，语雀在蚂蚁体系内是巨大的负担，成本远大于收益：
语雀在未商业化之前，是集团内部代替 confluence 存在的，因为内部的文档资料实在太多，confluence 的性能不够，所以在内部就做了一个 yuque，而且这个东西是前端的团队维护的。团队规模还小的话，用起来还好，但是一旦商业化，大规模用了，那性能就肯定是巨大的瓶颈了。这个产品主要是前端团队主导，大量的后端都是用 NodeJS 写的，这就养了一批独立集团内部 Java 体系之外开发人员，这样无论是现有的集团账号架构、高可用架构都没法直接复用，所有就有了大量需要重复造轮子的事情发生，这些都是要成本的。
语雀的技术架构演进历程
公开信息显示，语雀于 2016 年孵化自蚂蚁科技。当时，蚂蚁金融云需要一个工具来承载它的文档，负责的技术同学利用业余时间搭建了这个文档工具。当时，语雀底层服务完全基于体验技术部内部提供的 BaaS 服务和容器托管平台：
Object 服务：一个类 MongoDB 的数据存储服务；
File 服务：阿里云 OSS 的基础上封装的一个文件存储服务；
DockerLab：一个容器托管平台。
2017 年，为了应对业务发展带来的挑战，语雀团队主要从下面几个点进行改造：
BaaS 服务虽然使用简单成本低，但是它们提供的功能不足以满足语雀业务的发展，同时稳定性上也有不足。所以语雀团队将底层服务由 BaaS 替换成了阿里云的 IaaS 服务（MySQL、OSS、缓存、搜索等服务）。
Web 层仍然采用了 Node.js 与 Egg 框架，但是业务层借鉴 rails 社区的实践开始变成了一个大型单体应用，通过引入 ORM 构建数据模型层，让代码的分层更清晰。
前端编辑器从 codeMirror 迁移到 Slate。为了更好的实现语雀编辑器的功能，语雀团队内部 fork 了 Slate 进行深入开发，同时也自定义了一个独立的内容存储格式，以提供更高效的数据处理和更好的兼容性。
2018 年初，语雀开始正式对外提供服务，进行商业化。为了应对业务发展，语雀的架构也随之发生了演进：将底层的依赖完全上云，全部迁移到了阿里云上，阿里云不仅仅提供了基础的存储、计算能力，同时也提供了更丰富的高级服务，同时在稳定性上也有保障：
丰富的云计算基础服务，保障语雀的服务端可以选用最适合语雀业务的的存储、队列、搜索引擎等基础服务；
更多人工智能服务给语雀的产品带来了更多的可能性，包括 OCR 识图、智能翻译等服务，最终都直接转化成为了语雀的特色服务。
而在应用层，语雀的服务端依然还是以一个基于 Egg 框架的大型的 Node.js Web 应用为主。但是随着功能越来越多，也开始将一些相对比较独立的服务从主服务中拆出去，可以把这些服务分成几类：
微服务类：例如多人实时协同服务，由于它相对独立，且长连接服务不适合频繁发布，所以语雀团队将其拆成了一个独立的微服务，保持其稳定性。
任务服务类：像语雀提供的大量本地文件预览服务，会产生一些任务比较消耗资源、依赖复杂。语雀团队将其从主服务中剥离，可以避免不可控的依赖和资源消耗对主服务造成影响。
函数计算类：类似 Plantuml 预览、Mermaid 预览等任务，对响应时间的敏感度不高，且依赖可以打包到阿里云函数计算中，语雀团队会将其放到函数计算中运行，既省钱又安全。
随着编辑器越来越复杂，在 Slate 的基础上进行开发遇到的问题越来越多。最终语雀还是走上了自研编辑器的道路，基于浏览器的 Contenteditable 实现了富文本编辑器，通过 Canvas 实现了表格编辑器，通过 SVG 实现了思维导图编辑器。
参考链接：
https://mp.weixin.qq.com/s/WFLLU8R4bmiqv6OGa-QMcw
https://www.zhihu.com/question/627418678
https://www.infoq.cn/article/DSCQEMsmoIEXjFLtuw5C?utm_campaign=geek_search&utm_content=geek_search&utm_medium=geek_search&utm_source=geek_search&utm_term=geek_search